Make assumptions explicit.
Explicit data contracts → safer schema changes. Define fields, types, ownership, freshness expectations, and compatibility rules at the boundary. A consumer should not have to reverse-engineer meaning from a sample row.
About / engineering point of view
Build the conditions for trustworthy intelligence.
I’m Ketut Garjita. My focus is the data engineering underneath AI and analytics: systems that make inputs understandable, transformations testable, and operational behaviour visible.
The work beneath the model
Data foundations are product infrastructure.
input → evidence
A model can only be as dependable as the path that turns raw events into usable evidence.
AI systems inherit the ambiguity, delay, and missing context of their upstream data. A compelling model output does not remove a broken ingestion boundary, an undocumented transformation, or a silent schema change. It can make those failures harder to see.
That is why the engineering work matters: define what data means, preserve where it came from, validate what changed, and make the system’s limits visible to the people who operate it. The goal is not ceremony around pipelines. It is a shorter path from a surprising result to an explanation that can be acted on.
Working principles
A principle should change the system.
These are practical preferences, expressed as engineering consequences rather than biography or broad claims.
Prefer reproducible transformations.
Reproducible logic → defensible results. Version the code and configuration that shape a dataset, keep time and environment assumptions visible, and make a result possible to rebuild rather than merely admire once.
Let quality checks fail visibly.
Observability → faster diagnosis. Freshness, volume, null rates, distribution changes, and failed assertions should produce signals with context. A green scheduler is not proof that useful data arrived.
Orchestrate outcomes, not just jobs.
Meaningful dependencies → reliable delivery. Scheduling is only one part of orchestration. Retries, idempotency, backfills, dependency boundaries, ownership, and failure recovery determine whether a pipeline behaves well under change.
Choose architecture against constraints.
Constraint-led design → proportionate systems. Latency, cost, lineage, throughput, operational burden, and maintenance horizon matter together. The most elaborate architecture is not automatically the most responsible one.
Document the decisions people need.
Useful documentation → faster collaboration. Record the purpose, ownership, failure modes, trade-offs, and recovery path. Documentation earns its place when it helps someone safely operate or change a system.
How to work together
Clear interfaces. Direct feedback. Shared context.
Collaboration on technical work is strongest when the problem, constraints, and definition of “done” are visible early. A useful working rhythm is to establish the data boundary, surface the riskiest assumption, test a small slice, and then make the trade-offs legible before expanding the system.
That approach leaves room for disagreement without turning architecture into theatre. It also keeps conversations grounded in operational questions: who owns this data, what happens when it is late, how will a change be detected, and what does the team need to maintain six months from now?
Useful starting point
Bring a pipeline, dataset, AI workflow, or analytics problem where reliability, clarity, or scale is the constraint to investigate.
Continue through the portfolio
Review the work, then start a conversation.
Explore the project work for concrete system examples, or review the skills page for the technical areas represented in this portfolio. For a role, collaboration, or engineering discussion, use the contact route.